W-CDMA (Wideband Code Division Multiple Access) is a radio interface for IMT-2000 system (International Mobile Telecommunication system), which was standardized for use as the 3.sup.rd generation wireless mobile telecommunication system. It provides a variety of services such as voice services and multimedia mobile communication services in a flexible and efficient way. The standardization bodies in Japan, Europe, USA, and other countries have jointly organized a project called the 3rd Generation Partnership Project (3GPP) to produce common radio interface specifications for W-CDMA.
The standardized European version of IMT-2000 is commonly called UMTS (Universal Mobile Telecommunication System). The first release of the specification of UMTS has been published in 1999 (Release 99). In the mean time several improvements to the standard have been standardized by the 3GPP in Release 4, Release 5 and Release 6. A discussion on further improvements is ongoing under the scope of Release 7 and Study Item on Evolved UTRA and UTRAN.
UMTS Architecture
The high level Release 99/4/5 architecture of Universal Mobile Telecommunication System (UMTS) is shown in FIG. 1 (see 3GPP TR 25.401: “UTRAN Overall Description”, incorporated herein by reference, available from http://www.3gpp.org). The UMTS system consists of a number of network elements each having a defined function. Though the network elements are defined by their respective function, a similar physical implementation of the network elements is common but not mandatory.
The network elements are functionally grouped into the Core Network (CN) 101, the UMTS Terrestrial Radio Access Network (UTRAN) 102 and the User Equipment (UE) 103. The UTRAN 102 is responsible for handling all radio-related functionality, while the CN 101 is responsible for routing calls and data connections to external networks. The interconnections of these network elements are defined by open interfaces (Iu, Uu). It should be noted that UMTS system is modular and it is therefore possible to have several network elements of the same type.
In the sequel two different architectures will be discussed. They are defined with respect to logical distribution of functions across network elements. In actual network deployment, each architecture may have different physical realizations meaning that two or more network elements may be combined into a single physical node.
FIG. 2 illustrates the current architecture of UTRAN. A number of Radio Network Controllers (RNCs) 201, 202 are connected to the CN 101. Functionally, the RNC 201, 202 owns and controls the radio resources in its domain and typically terminates the Radio Resource Control protocol on the access network side. Each RNC 201, 202 controls one or several base stations (Node Bs) 203, 204, 205, 206, which in turn communicate with the user equipments. An RNC controlling several base stations is called Controlling RNC (C-RNC) for these base stations. A set of controlled base stations accompanied by their C-RNC is referred to as Radio Network Subsystem (RNS) 207, 208. For each connection between User Equipment and the UTRAN, one RNS is the Serving RNS (S-RNS). It maintains the so-called Iu connection with the Core Network (CN) 101. When required, the Drift RNS 302 (D-RNS) 302 supports the Serving RNS (S-RNS) 301 by providing radio resources as shown in FIG. 3. Respective RNCs are called Serving RNC (S-RNC) and Drift RNC (D-RNC). It is also possible and often the case that C-RNC and D-RNC are identical and therefore abbreviations S-RNC or RNC are used. Commonly, a Drift RNS 302 is used for soft handovers of UEs between different RNS.
General Description of the Protocol Model of the UTRAN Terrestrial Interfaces
FIG. 4 shows an overview of the protocol model of the UTRAN in an UMTS network. For a better understanding, only a brief description is provided herein; further details may be found in Holma et al., “WCDMA for UMTS”, Third Edition, Wiley & Sons, Inc., October 2004, Chapter 5, incorporated herein by reference.
On the horizontal plane, the protocol model can be split into the radio network layer and the transport network layer. All UTRAN-related issues are visible and handled on the radio network layer, while transport network layer typically represents standard transport technology that is selected to be used for data transport for the UTRAN without any UTRAN-specific changes.
On the vertical plane, the protocol model can be split into control plane and user plane. The control plane is used for UMTS-specific control signaling (i.e. signaling related to radio and transport interfaces) and includes the Application Protocol (AP), e.g. RANAP on the Iu interfaces, RNSAP on the Iur interfaces, NBAP on the Iub and RRC on Uu interfaces. The control plane functions and Application Protocol allows setting up traffic radio bearers to the UEs via so-called signaling radio bearers.
While the control plane protocols are responsible for the UNITS-specific control signaling, the user plane transports the data streams sent by and sent to the users, such as voice calls, streaming data, packets of packet-switched services, etc. For transport, the user plane contains the so-called traffic radio bearers (also sometimes referred to as Data Bearers).
The transport network control plane is used for control signaling within the transport network layer and does not include any radio network layer related information. The transport network control plane includes the ALCAP protocol, which is used to set up the traffic bearers for exchanging user plane information and the signaling bearers required for communicating ALCAP protocol messages. Due to the presence of the transport network control plane, it is possible that the Application Protocol within the control plane may operate completely independent from the technology selected for data transport on the traffic radio bearers in the user plane. The transport network control plane controls the operation of the transport network user plane.
UTRA Radio Interface Protocol Architecture
An overview of the radio interface protocol architecture of the UTRAN is shown in FIG. 5. Generally, the radio interface protocol architecture of the UTRAN implements Layers 1 to 3 of the OSI protocol stack. The protocols terminated in the UTRAN are also referred to as the access stratum (protocols). In contrast to the access stratum, all protocols not terminated in the UTRAN are typically also referred to as the non-access stratum protocols.
As has been discussed with respect to FIG. 4, the vertical split of the protocols into user plane and control plane is illustrated. The Radio Resource Control (RRC) protocol is a Layer 3 protocol of the control plane which controls the protocols in the lower layers of the UTRA Radio Interface (Uu).
The RRC protocol is typically terminated in the RNC of the UTRAN, however other network elements have also been considered for terminating the RRC protocol in the UTRAN, e.g. the Node Bs. The RRC protocol is used for signaling of control information to control access to radio resources of the radio interface to the UEs. Further, there is also the possibility that the RRC protocol encapsulates and transports non-access stratum messages, which are usually related to control within the non-access stratum.
In the control plane, the RRC protocol relays the control information to Layer 2, i.e. the Radio Link Control (RLC) protocol, via signaling radio bearers through Service Access Points (SAPs). In the user plane the non-access stratum protocol entities may use traffic radio bearers to directly access Layer 2 via SAPs. The access may be made to the RLC directly or to the Packed Data Convergence Protocol which in turn provides its PDUs to the RLC protocol entity.
The RLC offers the SAPs to the higher layers. The RRC configuration defines how RLC will handle the packets, e.g. whether RLC is operating in transparent, acknowledged or unacknowledged mode. The service provided to the higher layers in the control plane and user plane by the RRC or PDCP are also referred to as signaling radio bearer and traffic radio bearer, respectively.
The MAC/RLC layer in turn offers its services to the RLC layer by means of so-called logical channels. The logical channels essentially define what kind of data is transported. The physical layer offers its services to the MAC/RLC layer, the so-called transport channels. The transport channels define how and with which characteristics the data received from the MAC layer are transmitted via the physical channels.
Logical and Transport Channels in UTRAN
In this section the mapping between logical channels and transport channels will be outlined referring for exemplary purposes to the UNITS architecture. The mapping of logical channels to transport channels may be utilized for some of the signaling messages within a RRC connection establishment procedure.
The characteristics and mapping of logical and transport channels for UTRA and E-UTRA are summarized in the following tables. Logical channels are mainly described by data type to be transmitted whereas transport channels are mainly described by respective transmission types and identification method.
The table below contains a description of logical and transport channels for UTRA and E-UTRA, respectively.
TABLE 1Logical (LCH)or TransportChannel characteristicChannel (TrCH)Direction:type vs. channelUplink (UL)MappingcharacteristicDataTransmissionor DownlinkIdentification(LCH −>and mappingTypeType(DL)methodTrCH)LCHBCCHsystemN/ADLN/ABCCH −>(BroadcastinformationBCHControl(broadcast)CHannel)CCCHcommonN/AUL or DLN/A, Note: thisCCCH −>(Commonservicelogical channel isFACH,Controlcontrolmainly used forRACHCHannel)(unicast)transmission ofcontrol planeinformation priorto identifierassignment to UEby radio accessnetworkDCCHdedicatedN/AUL or DLN/ADCCH −>(DedicatedserviceFACH,ControlcontrolRACH,CHannel)(unicast)DCHTrCHBCHN/ACommonDLN/A due toN/A(Broadcastchannel withbroadcast dataCHannel)statictypeconfigurationFACHN/ACommonDLLayer 2 inbandN/A(Forwardchannel withwhen carryingAccesssemi-staticDCCH, N/ACHannel)configurationotherwiseRACHN/ACommonULLayer 2 inbandN/A(Randomchannel withwhen carryingAccesssemi-staticDCCH, N/ACHannel)configurationotherwiseand contention-based accessDCHN/ADedicatedUL or DLN/A since this isN/A(Dedicatedchannel withdedicatedCHannel)semi-statictransport channelconfiguration
Please note that mapping of DCCH in the table above may be possible on a Fractional Dedicated Channel in downlink direction for UMTS Release 6 and on Enhanced Dedicated Transport Channel in uplink for UMTS Release 6 of the Evolved UTRA. These options have however not been considered in the table for the sake of simplicity.
For UTRA, identification of transport channels as shown in the table above is Layer 2 inband. Layer 2 inband identification means that header of a Layer 2 MAC PDU contains UE identifier pointing at a specific UE as a destination or source of information for downlink or uplink direction, respectively. Consequently, for mapping of logical channels containing data of system information and common service control type identification is not needed. Identification is applicable only to common transport channels (RACH and FACH) apart from broadcast common transport channel (BCH).
The following table shows an exemplary description of logical channels and transport channels in the Evolved UTRA (E-UTRA).
TABLE 2Logical (LCHor TransportChannel characteristicChannel (TrCH)Direction:type vs. channelUplink (UL)MappingcharacteristicDataTransmissionor DownlinkIdentification(LCH −>and mappingTypeType(DL)methodTrCH)LCHBCCHsystemN/ADLN/ABCCH −>(BroadcastinformationEvolved-Control(broadcast)BCHCHannel)CCCHcommonN/AUL or DLN/A, Note: thisCCCH −>(Commonservicelogical channelSDCH (inControlcontrolis mainly useddownlinkCHannel)(unicast)for transmissiondirectionof control planeonly), CACHinformationprior toidentifierassignment toUE by radioaccess networkDCCHdedicatedN/AUL or DLN/ADCCH −>(DedicatedserviceSDCH,ControlcontrolSUCHCHannel)(unicast)TrCHEvolved-BCHN/ACommonDLN/A due toN/A(Evolvedchannelbroadcast dataBroadcastwith statictypeCHannel)configurationCACHN/ACommonULLayer 2 inbandN/A(Contentionchannel withwhen carryingAccesssemi-staticDCCH, N/ACHannel)configuration andotherwisecontention-basedaccessSDCHN/ASharedDLLayer 1N/A(Sharedchannel withoutbandDownlinkdynamic configurationCHannel)and scheduledaccessSUCHN/ADedicatedULLayer 1N/A(Sharedchannel withoutbandUplinksemi-staticCHannel)configuration
It can be noted that legacy EACH is not used and that shared channels are used instead of legacy DCH. It is assumed that associated physical channels in downlink direction are used for both SDCH and SUCH. An example of associated physical channel could be Shared Control Signaling CHannel (SCSCH).
The transmission types description in the respective column of the table above should be understood as follows. A static configuration means that the transport format attributes of the channel, e.g. modulation, forward error correction scheme etc. are system-specific and are not subject to change by the network. In a semi-static configuration the transport format attributes of the channel, e.g. modulation, forward error correction scheme etc. are subject to change by reconfiguration procedure. The procedure is fairly slow introducing latency of the order of 100 ms. Finally, in a dynamic configuration the transport format attributes of the channel, e.g. modulation, forward error correction scheme etc. are subject to change by signaling on associated control channels. The procedure is fairly fast relative to semi-static reconfiguration and may introduce a delay of the order of several sub-frames (1 sub-frame˜0.5 ms). Dynamic configuration may be carried out so as to optimally match transmission format to temporal variations of radio channel in which case it may be referred to as link adaptation.
Information that may be transmitted by this channel is given in the table below:
TABLE 3Control signalingControl signalingfor downlinkfor uplinkPhysicalDemodulationTransmission power control bitscontrolChunk allocationTransmission timing control bitsinformationACK/NACK bit for the reservationData modulationchannel and fast access channelTransport block sizeL2SchedulingSchedulingcontrolUE identityUE identityH-ARQChunk allocation informationH-ARQ processData modulationinformationTransport block sizeRedundancy versionH-ARQNew data indicatorACK/NACK
It can be seen from the table that UE identification information is contained in both downlink and uplink directions. Thus, by virtue of Layer 1 outband identification, having decoded the data on the SCSCH and having determined that the identifier transmitted on the associated physical channel corresponds to the identifier assigned to the UE during the RRC connection establishment procedure, the UE can receive physical channels on which respective shared transport channels are mapped and further process Layer 2 PDUs (Protocol Data Units) corresponding to SDCH and SUCH shared transport channels. Identification for CACH transport channel is analogous to the identification for RACH transport channel in E-UTRA. It can be concluded that identification is applicable to common and shared transport channels (CACH, SDCH and SUCH) apart from evolved broadcast common transport channel (Evolved-BCH). Identification for said common transport channels is of L2 inband type, while the identification for shared transport channels is of Layer 1 outband type.
From the definitions of “Layer 2 inband” and “Layer 1 outband” identification one could infer that there is one and only one identifier per UE. Hence, once a Signaling Radio Bearer has been established, the UE has been assigned identifier that can be used for Traffic Radio Bearer as well. However, it is possible that multiple identifiers per UE are defined and used per configured transport channel.
Spectrum Allocation
With respect to stand-alone operation of the mobile terminals spectrum allocations of different sizes (e.g. 1.25 MHz, 2.50 MHz, 5.00 MHz, 10.00 MHz, 15.00 MHz and 20.00 MHz) have been suggested in 3GPP TR 25.912, “Requirements for Evolved UTRA (E-UTRA) and Evolved UTRAN (E-UTRAN)”, version 7.1.0 (available at http://www.3gpp.org). It can be shown that data rate of evolved Primary Common Control Physical Channel (P-CCPCH—in legacy system, the BCH transport channel is mapped to the P-CCPCH) varies depending on size of spectrum allocation (as indicated in the table below), assuming that configuration of Evolved Broadcast Transport Channel is semi-static.
TABLE 4[MHz]1.252.505.0010.0015.0020.00[kbps]4.008.0016.0032.0048.0064.00,
It can concluded that the UE reading time for reading a predetermined amount of data from the physical channels depends upon spectrum allocation. Therefore, for smaller spectrum allocations, the UE reading time and thereby power consumption is increased. Furthermore, when the data size implies the transmission of the data over several transmission time intervals (TTIs), the UE has to power its receiver to receive data at all TTIs in which the data is provided. For larger spectrum allocations, the UE reading time is decreased, but if several data portions are sent in one TTI, UE may need to decode irrelevant portions in that TTI, since the receivers may typically only be tuned to receive data of a complete TTI. This may also lead to unnecessarily increased UE power consumption.
The potential shortcomings outlined above are illustrated in FIGS. 8 and 9 for the transmission of broadcast system information (BSI), which is typically partitioned into system information blocks (SIBs) in UMTS (FIG. 7). From FIG. 8, it can be recognized that for a spectrum allocation size of 5.00 MHz, the UE has to receive contents of the broadcast control channel BCCH over two successive TTIs to acquire information contained in SIB8, even though possibly MIB (at a given time instant) and SIB719/10 may not be of interest for the UE. Also, for larger spectrum allocations, e.g. of the size 10.00 MHz, as shown in FIG. 4, the UE decodes the master information block MIB and SIB1. In addition, the UE also decodes SIB2 and SIB3 even though the contents of these information blocks may not be necessary for system access or elementary mobility functions